Subject: Re: Comments on scalability proposal

From: David Bryant/HQ/3Com <[email-masked]>
Date: 4 Aug 95 15:23:18 EDT

Ravi - 

I don't want to create a long list of old information, so please forgive 
that I haven't included all past emails in my response.   Rather than spend 
a lot of time on each of my individual points let me see if I can summarize 
the important ones.

1).Lots of work to be done

The proposal can clearly be made to solve SOME scalability related issues.  But 
there is much work to do between what is written in the proposal and what would 
ultimately need to be documented by the AIW in terms of an AIW-standards 
specification.

2).Doesn't really solve much

I think the scalability RIG identified 3 kinds of scalability issues they
were looking to resolve:
 
 Broadcast traffic load on the SSPs and network bandwidth
 CPU/Memory load on systems with a lot of DLSw peers
 Administrative burdens in configuration related to the number of DLSw
       peers

Seems the proposal in question is primarily targeted at the first situation
when one has a network with a large number of DLSw peers that must all talk
to one another and there's a lot of broadcast traffic.  This is typically a
NetBIOS oriented scenario.  The proposal doesn't seem to do much for the 
second issue which is prevelant in SNA networks with a few number of host 
data centers.  In addition, the proposal only aggrevates the third issue 
in the sense of creating a whole bunch of other new parameters to control 
network scalability and efficiency.

3). Non-Standard approach

I realize the proposal was brought to the AIW for endorsement as a standard,
but my concern is that it's new technology on top of DLSw which make DLSw even 
more unique in the world of networking and less synergistic with other 
approaches
to similar problems in the industry.  In general, I'd prefer to see a solution 
that leverages other industry accepted standards... rather than create new ones.

4). Other alternative exist 

Let me propose two other possible solutions to the scalability issues listed 
above: 

4a: DLSw Single Switches/BAN/SNA Boundary Routing

A number of us in the industry have implemented solutions which essentially
create a DLSw implementation that takes LLC2/SDLC in one side and puts it out
the other side of the box in LLC2/SDLC.  Bay Networks call's it DLSw Single 
Switch
configurations, IBM calls it BAN function, Sync Research calls it LLC2 
Switching,
3Com calls it SNA Boundary Routing.  There are lots of ways to do it, but 
essentially, 
it's like taking the TCP/IP tunnel part of DLSw and collapsing it into one box 
and 
replacing TCP/IP with a stub.  This is pretty simple to implement and it can be 
used  
at the outer edges of the network as a feed in point to regional concentration 
centers 
which then "DLSw's" the traffic to where it needs to be.    

This seems easier to implement, easier to understand, and resolves all three of 
the 
scalability issues.

We could discuss this further over the internet or at the AIW.

4b: Make use of multicast addressing in TCP/IP

If we make use of the multicast addressing of TCP/IP, we can effectively reduce 
administration burdens by dynamically discovering DLSw peers and establishing
tunnels as necessary.  We can reduce broadcast overhead by sending the 
broadcast 
packets over the multicast function.  We'll likely need to do something 
else/more
to resolve scalability issues with typical SNA single data center networks.   
We might be able to use this in conjunction with 4a as well.

But effectively, this provides all the same benefit as the existing proposal 
except 
that it uses existing standards (IP Multicast) and creates greater synergy 
between 
DLSw and mainline network industry trends and directions. 

I encourage others to chime in as appropriate via the internet.  In the 
meantime, I gather 
we have things to discuss at the upcoming AIW.  And I don't get the sense we've 
reached
any concensus toward moving forward with the existing proposal for AD status at 
AIW8. 

Regards, 
Dave Bryant
3Com Corporation
[email-masked]

PS. Who's handling the Riglet scheduling for the AIW?  (Louise?) I think the 
scalability riglet is likely to need a 
substantial amount of time (like one day) to discuss various issues etc.